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For the last several years I have been trying to advocate a very ninor 
change to the AX 25 protocol. This change wll allow the protocol to be nuch 
nore conpati ble wth our nultiple access half duplex radio channels. | 
requested that the digital conmittee consider including this change in the 
protocol specification. The connittee indicated that the idea night have sone 
nerit. They suggested that I get sone test code witten to try it out on the 
air. Since that tine, I have worked wth Howard Goldstein, N2WX to get sone 
beta test code witten so that this prioritized acknow edgenent (PRI ACK) 
channel access system could be evaluated on the air. What follows is a very 
non-rigorous description of the nodified protocol. 


While prinarily intended to inprove channel perfornance on HF, this 
system wll also be useful on any VHF sinplex channels where there are hidden 


terminals. 


BETA test code is now avail able fromne for anyone who is genui nel y 
interested in participating in the test AND REPORTING THEIR FINDINGS. I have 
no interest in sinply distributing ROM and then never receiving any feedback 
fromthe user. Two things are needed at this tine. First, reports of bugs or 
protocol viol ations would be nost useful for tuning the firnware so that the 
protocol nodi fication itself can be neani ngfully eval uated. Second, a valid 
quantitative test of the effect of the protocol nodification on a multiple 
access HF channel needs to be done. The code I have is for TNC-2 clones and 
the MFJ-1278. I can be reached at: 


Eric Gustafson, N7CL 
2018 S. Avenida Planeta 
Tucson, AZ 85710 
(602)-747-1410 


I wuld prefer to deal directly wth area test coordi nators on 
Conpuserve. Those interested in beconing an "area test coordinator" shoul d 
contact ne in section 9 of the HAMNET forumon ConpuServe. Use a subj ect 
keyword of "PRIACK". My ConpuServe nunber is 71750,2133. 


| had originally intended to report the results of testing done at HF 
and VHF in this paper. The initial results of VHF testing done here locally 
on two si npl ex LANs is very encouraging. Even wth snall nunbers of users on 
the channel the inprovenent was quite dranatic. Putting the code into the TNC 
of a BBS which was on 145.01 (along wth users and node inputs) had the effect 
of naking the channel functional again for the users. Previously, whenever 
soneone accessed the BBS, all other activity on the channel effectively cane 
to a halt. So far we have noted no instances of inconpatibility wth the old 


protocol. 


Unf ortunatel y, HF testing has been slowto get off the ground since both 
of the initial beta test groups have a | arge contingent of nenbers who are 
using PK-232 TNCs. Until recently this neant that these nenbers couldn't 
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partici pate in the test due to not having PRI ACK code avail able for the PK- 
232 This has now been corrected. AEA has recently nade sone beta test code 
avail able for the PK-232. | understand that AEA is planning on including 
PRI ACK in an upconing release of generally available code. Hopefully, we can 
now do a neaningful test of the PRI ACK system on H. 


DESCRIPTION 


The idea behind the prioritized acknow edgenent (ACK) protocol is quite 
sinple. The idea is to give ACKs priority access to the channel so that tine 
is not wasted retrying packets that have already been correctly copied but for 
whatever reason, the ACK is not received wthin the tine limt defined by the 


FRACK (T1) tiner. 


The present protocol does not handle a si npl ex LAN wth hidden terninals 
as well as it possibly could. This is prinarily because, the present protocol 
is nore likely to synchronize collisions wth acknow edgenent packets than 


Wth any other type of packet. 


To this collision synchroni zation nechanismthe current version of AX 25 
adds a propensity to cause even ACKs which are not fromhi dden terninals (and 
therefore less susceptible to collision) to be delayed beyond even generous 
FRACK tiner settings when the channel gets busy. 


Qnce the FRACK tiner tines out, even if the ACK finally nakes it through 
before the retry is sent, the original packet is retried anyway. This 
obvi ous|l y wastes a lot of tine which could be better used clearing the channel 
of sone of the legitinate offered | oad. 


It is this feature of the current AX 25 protocol that accounts for nost 
of the abysnally poor perfornance of the currently popul ar NETROM and THENET 
nodes when they are used as onnidirectional single channel (or even 
nul tichannel if there is nore than a single other node on each channel ) 
systens. Poor receiver not ready (RNR) condition handling by the current 
protocol is also a contributor here. It should be noted that these node chi ps 
CAN handle point to point links to a single other node perfectly adequatel y. 


The prioritized ACK protocol avoids the above probl ens by gi ving ACKs 
priority access to the channel. It does this in such a way that even ACKs 
coning from hidden terninals are protected fromcollision. The current 
protocol gives a limited version of this priority access only to di gi peated 
franes. 


ACK pri oriti zation works wth slotted channel access in the follow ng 
way: 

1. Response franes (ACKs) are al ways sent i nnedi ately wth no tine del ays 
unrel ated to hardware limitations applied. Utinately, not even data 
carrier detect (DCD) should be checked for sending an ACK. Hovever, in 
the current beta test code, DCD wll still hold an ACK off the channel. 
This was necessary to all ow conpati ble operation wth non PRI ACK 
stati ons. 
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2. Stations queued up to access the channel but waiting for a channel busy 
condi tion (DCD true) to clear, wll start a slotted access procedure only 
AFTER enough tine for a response frane to clear the channel has 
transpired (whether or not the response frane is detectable by the queued 
up station). 


3, Slot tine whndovw are selected to be large enough that the local TNC wll 
be able to unanbi guous! y deternine whether any other detectable station 
has selected any slot preceding the slot selected by the local TNC. This 
is to prevent two TNCs which have sel ected adj acent slots fromcolli ding 
anyhow 


As you can see, under this protocol there wll never be a condition 
where an ACK is delayed from being sent beyond the FRACK tiner limitation. In 
fact, the FRACK tiner becones relatively neaningless in this context. 

Hovever, the FRACK tiner is still required to nai ntain conpatibility wth 
stations who are not running PRI ACK code. When all station are running the 
PRI ACK system the TNCs know that if they don't see the ACK i nmedi atel y when 
expected, they are never going to See it. 


FRACK can be used to force del ayed reaccess to the channel when an ACK 
hasn't been recei ved when expected. However, when all stations on the channel 
are running PRI ACK, both FRACK and calcul ated backoff types of access control 
are conpletely unnecessary. Here | amassuning that end to end AC di gi peating 
wll be phased out of the protocol specification now that networki ng 
devel opnent has begun. If layer 2 digi peating nust continue to be supported 
(yech!), we should at least convert to point to point ACKs for this purpose. 


Q a narginal channel which is lightly | oaded, calcul ated backoffs will 
do exactly the wong thing by backing off reaccess tines on the assunpti on 
that nonrecei pt of ACKs is due to collisions. Under the sane ci rcunstances, 
PRIACK wil try to get through whenever it isn't deferred by DCD being true. 

If the channel truly IS busy, PRI ACK equitably distributes the channel 

bandw dth across all the users. This fair distribution is prinarily a result 

of using p-persistence slotted channel access control ala Karn and Lloyd [I]. 

It is the conbi nation of prioritized acknow edgenents and carefully structured 
slotted access control that makes PRI ACK so effective. 


Enforcing a channel access delay for all stations on the channel for 
whomthe packet that caused the queue was not intended (and who therefore 
aren't going to ACK it) allows even ACKs fromhi dden terninals to get back to 
the expecting station. This clears that traffic fromthe offered load list. 
If the packet was indeed copied and ACKed, further retries of the sane . 
infornation wll not be necessary. 


The beta test code for this nodi fication to the protocol is conpati ble 
wth stations using the current protocol. A station using the new protocol 
will not degrade the channel for users of the current protocol. So there is 
nothing wong wth firing up the newstuff on a channel where the naj ority of 
the users aren't yet using it. Several of us here in the Tucson LAN have been 
running PRI ACK exclusively for over nine nonths now Cher stations on the 
LAN are (so far) conpletely unaware of this fact. 


HARDWARE LIMITATIONS 


This protocol wll not work well if the TNC’s nodem DCD characteristics 
are not very good, but neither wll any other CSM based protocol. 


If the TNC uses the 2211 denodul ator, the DCD characteristics can be 
readily optimzed. A relatively sinple nodification to the DCD circuit of 
these denodul ators is all that is required to nake the DCD reliable enough to 
base a CSM\ system on. 


If the TNC uses one of the single chip nodens intended for land line use 
(like the AMD7910 or TMS3105) or a filter based nodemlike the PK 232, all is 
not lost but a nuch nore extensi ve nodi fication is required to rehabilitate 
the DCD circuit. 


The infornation needed for both of these nodi fications is in ny paper in 
the proceedings of the Seventh ARRL Conputer Networking Conference [2]. In 
addi tion, TAPR has nade circuit boards available which elininate hacking the 
TNC circuit board in the case of the 2211 and eliminate the tedious state 
nachine wring task in the case of the other nodens. 


In particular, if your DCD circuit has a high false DCD duty cycle when 
listening to noise on an enpty channel, the protocol's ACKWIT characteristic 
wll virtually prevent you from being able to transmt at all. The DCD 
circuit MUST be able to reliably detect the presence of a data carrier but it 
MUST NOT be constantly chattering away on noise. 


TERRESTRIAL APPLICATION ONLY 


The PRI ACK systemis applicable only to terrestrial connuni cations and 
only in the half duplex radio environnent. Long path delays, ALOHA channels, 
and full duplex point to point links all have different requirenents and 
should have protocol specifications tuned to the specific application. Mbst 
of our layer2 problens have cone fromone of two sources. Me is trying to 
incorporate higher level functions in the layer 2 specification (CHECK etc.). 
The other is fromtrying to nake one layer 2 protocol fit nany differing | ayer 
1 topologies. Unfortunately, what is going on at Iayer | DOES affect the way 
the layer 2 protocol should be structured. 


CONCLUSI ON 


If we are to optimze our anateur radio protocols, we wll have to tune 
the protocol specifications to optimze efficiency based on the layer | 
limtations specific to the application. [believe that the PRI ACK systemis 
a necessary protocol tweak for use on terrestrial nultiple access half dupl ex 
radio channels. 


Special thanks to: 
Hovard Gol dstein, N2WX, who coded these protocol nodi fications into the TNC 2 


AX 25 code so that we can begin testing wth enough stations to nake a useful 
statenent about perf ornance. 
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Martin F. Jue, and Steve Pan of MJ Inc. for allowng ne to release sone 1278 
V2.3 EPROMS wth this nodified protocol installed. This wll be a very big 
help in testing on HF where the need is greatest. 


AEA Inc. for devoting the resources to providing PRI ACK code for their PK- 232. 
This wll be a big help in getting a neaningful HF test acconpl i shed. 


Lyle Johnson, WA/7GXD, who has contributed nany hours ki bitzing about the 
various aspects of the protocol and considerable tine partici pating in the 
prelimnary on air testing. 

Dan Mrrrison, KV7B, whose contribution has been sinilar to Lyle’s. 


Gail Peterson, N7BXX, who has been hel ping out wth the preliminary on air 
testi ng. 


Mykl e Raynond, N7JZT, who has been hel ping out wth the preliminary on air 
testi ng. 
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